🬤 rns.recipes

Forum / General / Thread / Export

# Adding 915Mhz band to Xaio ESP32S3/SW1262

_General · started by charlieb on Sat, Jul 18, 2026 8:13 PM_

---

## Original post

**charlieb** · Sat, Jul 18, 2026 8:13 PM

I have a bunch of these tiny devices and I'm starting to actually want to use them for experimentation. The version of RNode_Firmware_CE on liberatedsystems/RNode_Firmware_CE does not have this enabled so I added it.

https://github.com/charlieb/RNode_Firmware_CE

The stock rnsd on markqvist/Reticulum did not like that so I had to make some changes over there too.

https://github.com/charlieb/Reticulum

I'm not quite ready to PR because I haven't fully tested that I can get two of these devices to talk to each other on 915MHz but that's my next task.

In the meantime ... markqvist/Reticulum says that development is happening elsewhere, that says to me that actually I shouldn't PR against that repo but it doesn't say where I should PR. So where should I PR this, assuming it actually works?

Cheers,

Charlie

---

## Reply 1

**charlieb** · Sun, Jul 19, 2026 2:54 PM

Well the testing did not go well. It was super crashy on all frequencies, not just the one I added. After trying a bunch of different things I decided it was easier to steal than to be original. So I had claude port part of RadioLib from meshcore over to the reticulum stack just for this device. That worked well and now these cheap little devices can be rnodes.

I expect this is objectionable on a couple of points: use of AI and adding external dependencies but I can't argue with the results. I'm an application level programmer so this would have taken months for me to figure out on my own.

---

## Reply 2

**Anonymous** · Sun, Jul 19, 2026 7:14 PM

**charlieb** wrote:

> Well the testing did not go well. It was super crashy on all frequencies, not just the one I added. After trying a bunch of different things I decided it was easier to steal than to be original. So I had claude port part of RadioLib from meshcore over to the reticulum stack just for this device. That worked well and now these cheap little devices can be rnodes.

In my opinion the main firmware should really be ported to RadioLib since it supports more devices. Does anyone know why mark didn't?

---

## Reply 3

**charlieb** · Mon, Jul 20, 2026 12:55 AM

I asked claude about this before and it thought it was too much work and to invasive for me as a newbie to consider but now I ask:

I'm getting some positive noise about the idea of porting all of the RNode firmware to RadioLib. Please give me a list of things that would have be be changed to make that fit. I'm not interested in a shim solution but rather analyze a full migration to RadioLib.

And it says:

```

Based on a full pass through Radio.hpp/Radio.cpp (the actual driver), Boards.h (per-board config), and everywhere else RadioInterface is touched, here's what a genuine full port — replacing the hand-rolled opcode drivers everywhere, not just adding a shim — would involve.

The good news: the abstraction boundary is already clean

Only Radio.hpp/Radio.cpp (and now my Xiao adapter) ever reference the chip classes directly. Console, BLE, display code, Utilities.h, and RNode_Firmware_CE.ino all talk exclusively through the RadioInterface abstract base and the interfaces[]/interface_obj[] arrays. That

means the migration is contained to two files' worth of implementation, not a sprawling refactor.

1. Replace three driver classes with RadioLib-backed ones

Radio.hpp currently declares sx126x, sx127x, sx128x as three independent classes with duplicated opcode/SPI plumbing. RadioLib's PhysicalLayer interface is common across its SX1262/SX1276/SX1278/SX1280 classes, so this is a chance to collapse to one adapter class

parameterized over which RadioLib radio object it holds, instead of three. That's a real simplification opportunity, not just a mechanical swap.

2. Move per-board radio config out of #if BOARD_MODEL chains inside the driver

Right now TCXO voltage is hardcoded via a #if BOARD_MODEL == ... chain inside sx126x::enableTCXO() in Radio.cpp (3.3V for RAK4631/OPENCOM_XL/Heltec32V3/Xiao, 1.8V for T-Beam/T-Echo/T3S3/T-Deck/T-Beam-S/Heltec-T114/E22). RadioLib takes TCXO voltage as a plain begin()

parameter. This data belongs in Boards.h's per-board pin/config tables (same pattern I already used for the Xiao adapter), not compiled into the driver. Same treatment needed for the RFO-vs-PA_BOOST output selection currently hardcoded in sx127x::setTxPower().

3. Per-chip-family feature-parity checks (verify against RadioLib, don't assume)

- PA antenna-mismatch clamp workaround — sx126x::setTxPower() does a manual RegTxClampConfig register write per Semtech's errata. Need to confirm RadioLib's SX126x does this internally (it generally does, but must verify per version) rather than silently dropping it.

- Output power tables — the hand-tuned pa_buf/OCP values that hit exactly 22dBm on SX1262 need to be checked against RadioLib's own power-setting path so max EIRP doesn't drift on boards with regulatory certification tied to specific output levels.

- SF5/SF6 handling — already chip-family-conditional in getAirtime(); confirm RadioLib's low-datarate-optimization behaves the same at those edge SFs.

- packetFrequencyError() — implemented for sx127x but stubbed to 0 for sx126x/sx128x today. RadioLib exposes getFrequencyError() for all three — this migration is a chance to actually fill that in consistently instead of carrying the stub forward.

- getPacketValidity() / CRC-error IRQ mapping — same shape of check I did for the Xiao adapter, needed for both other chip families too.

4. DIO-sharing/interrupt logic, per chip family

Each family shares TX_DONE/RX_DONE IRQs across DIO pins differently (this was the trickiest part of the Xiao adapter). SX127x traditionally has more DIO pins available and doesn't need the same "am I mid-TX" flag trick SX126x does; SX128x's IRQ layout is closer to SX126x.

Each needs its own careful audit, not a copy-paste of the Xiao adapter's handleDio0Rise() logic.

5. Dual-radio board support

BOARD_OPENCOM_XL runs two interfaces simultaneously ({SX1262, SX1280}). Need to confirm RadioLib supports two independent Module/radio instances on separate SPI busses/IRQ pins concurrently without cross-talk — likely fine, but it's an explicit thing to test, not assume.

6. Build system

- Makefile's prep-esp32 needs the RadioLib install (already added for the Xiao work) — but prep-nrf needs it too now, since RAK4631/OpenCom XL/T-Echo/Heltec-T114 are all NRF52 and currently untouched.

- Flash/RAM budget: RadioLib compiles in support for many protocols (LoRa, FSK, GFSK, etc.) by default. The NRF52 boards are the tightest fit here — use RADIOLIB_EXCLUDE_* defines to trim to LoRa-only and verify against each board's upload.maximum_size in the Makefile

before assuming it fits.

7. Testing matrix

27 discrete firmware-* build targets exist today, covering ~20 board models across 4 chip families (mostly SX1276, several SX1262, one SX1278, one SX1280, one dual). A flag-day rewrite isn't realistic to validate — the sane rollout mirrors what happened with the Xiao

board: port one chip family at a time behind BOARD_MODEL/chip-family conditionals, keep the old driver reachable until each board is confirmed working over real RF, then delete the old path per family once its boards are all validated. Old Radio.cpp/Radio.hpp should only

be deleted after the last board's cutover, not before.

8. Loose ends carried over from the Xiao work

Still open from before: the license-header convention for new files, and whether to bump MAJ_VERS/MIN_VERS — both apply with more weight now since this would touch every board's reported firmware identity, not just one.

```

Now, given the trouble it had with debugging the existing SX1262 implementation, take all that with a big grain of salt. Plus it'll get immediately labelled slop which honestly I can't really evaluate because this isn't a domain I'm very knowledgeable about, which is why I'm using claude in the first place.

---

## Reply 4

**Anonymous** · Mon, Jul 20, 2026 4:35 PM

**Anonymous** wrote:

> In my opinion the main firmware should really be ported to RadioLib since it supports more devices. Does anyone know why mark didn't?

If i remember correctly, mark started RNode_Firmware before RadioLib had lora support, and before it was mature enough

---

## Reply 5

**charlieb** · Sat, Jul 25, 2026 4:11 PM

Turns out that micro reticulum firmware supports this device type quite nicely. So this is not needed.

---

## Reply 6

**bergie** · Sat, Jul 25, 2026 5:00 PM

**charlieb** wrote:

> So I had claude port part of RadioLib from meshcore over to the reticulum stack just for this device. That worked well and now these cheap little devices can be rnodes.

Could you post the sources of that port somewhere? Having a Radiolib version of RNode firmware would be great, as it would enable devices like the Seeed T1000e cards to be used with Reticulum.

We've been using these cards as our daily Meshtastic devices. Good battery life (a bit over two days), and they have GPS, alert buzzer, and are waterproof. The last point is quite crucial when going about in a dinghy.

---

## Reply 7

**charlieb** · Sun, Jul 26, 2026 6:36 PM

I would look into https://github.com/attermann/microReticulum

I believe that is already using RadioLib. I'll happily throw my port up if you really want but it's not like an active project.

---

## Reply 8

**anonygoose** · Mon, Jul 27, 2026 12:15 PM

The original T1000E support is still up at https://github.com/cobraPA/RNode_Firmware_iOS/tree/nrf52_t1000e_upstream. Hasn't been updated to latest version from Mark, also doesn't need RadioLib...

---

## Reply 9

**bergie** · Tue, Jul 28, 2026 12:26 AM

Not quite there yet, but: https://github.com/bergie/microReticulum_Firmware/tree/t1000e

---